1. Field of the Invention
The present invention relates generally to computers and computer software. More particularly, the present invention relates to a computer-implemented method, computer usable program code, and a data processing system for testing traces in a software program to improve performance of the software program.
2. Description of the Related Art
Modern software can be exceedingly complex. Testing modern software for errors can take more time and money than is acceptable. Thus, techniques for testing software more efficiently have been developed.
In one technique, test software traces are compared to reference software traces. A software trace, or trace or execution path, is an execution path followed by a particular software program. A trace can also be described as a set of points in a computer program that can be reached in a sequence during the execution of the computer program. A trace can also be a sequential log of contextual information captured during software execution. A software program can have many software traces. Each software trace has one or more components. A component is a function, test probe, or some other discrete property of an execution path. Thus, a test software trace is an execution path in a software program that is to be tested. A reference trace is an execution path that already has been tested for errors. A reference trace thus contains a number of known reference components that are assumed to be acceptably reliable. By comparing test software traces to reference software traces, software developers can concentrate error analysis only on those trace components that have not been analyzed or tested.
Unfortunately, some modern software is so complex that thousands of test traces exist in a software program. Worse yet, many thousands of reference traces may exist. Each test trace and/or reference trace may contain twenty million or more trace components. Thus, to simplify the process of comparing test traces to reference traces, software developers often compress test traces and reference traces to eliminate most information. For example, one current practice is to compress test traces and reference traces to caller/callee function pairs. Thus, only caller/callee function pairs are compared. Other compression techniques are known, but like the above example they are applied one at a time, with the resulting comparisons usually performed sequentially.
While this practice saves time, this practice is not efficient. While unanalyzed caller/callee function pairs might be identified, many other unanalyzed components in the test traces may go unidentified due to the loss of information during compression. Thus, the overall quality of the final software product might suffer from lack of testing of the unidentified components.